HaCKeRz Kr0nlcKLeZ 1

home *** CD-ROM | disk | FTP | other *** search

/ HaCKeRz Kr0nlcKLeZ 1 / HaCKeRz Kr0nlcKLeZ.iso / chibacity / retal.txt < prev next >

Wrap

Text File | 1996-04-22 | 14.0 KB | 294 lines

Computer Virus Developments Quarterly Retaliating Against Integrity Checkers A Retaliating Virus A Retaliating Virus is a virus which can retaliate against anti-viral measures which might be in place to frustrate its attempts to replicate within a computer sys- tem. Such viruses may prove to be as much of a setback to non-scanning techniques for catching viruses as self- mutating viruses have been to scanners. Here we will present the functional details of how a retaliatory virus might work on a PC which has basic anti-viral protection installed on it. This virus is called simply RETALIATOR. (Source code for RETALIATOR is included on the disk received by paid subscribers only.) To understand how RETALIATOR works, let's first look at a simple virus which infects EXE files. A flow chart for such a virus looks something like this: EXE file loaded by operating system | | | Virus gains control of the CPU | | | Search for uninfected EXE file | | | | | Infect file | | | Pass con- trol to host program Such a virus is normally caught by anti-viral software in three ways: 1) A scanner may know the signature of such a virus, and locate it in a piece of suspect software, and flag the user as to its presence. 2) A memory-resident behavior-checker could be look- ing for suspicious activity, and catch the virus in the act of replication. 3) An integrity checker could determine that a file which this virus infected had been changed. Then, either simple user awareness, or a type of dynamic scanning might be employed to track down the original source of the virus, once its spread was detected. A virus which retaliates against active measures will attempt to make the user regret using methods (2) or (3) to secure his system. A number of authors have made much of the the inability of viruses to fool various anti- viral measures like integrity checkers.' This is a rather difficult task if the integrity checker is properly imple- mented. However, a virus need not fool the anti-virus measure. It can just get mean, like a cornered animal fighting for its life. It can do that if it is not detected by a scanner and gains control of the CPU at least once. Such behavior could prove to be as detrimental to the integrity checker approach as if viruses could easily fool them. It will discourage people from using anything more than a scanner when they are already not inclined to do it. In this article, we will demonstrate just how easy it is to implement such anti-anti-viral measures. Memory-resident anti-viral behavior checkers generally hook interrupts 21H and 13H, among others, and monitor them for suspicious activity. They can then warn the user that something dangerous is taking place and allow the user to short-circuit the operation. Typical- ly, suspicious activity includes attempts to overwrite the boot sector, modify executable files, or terminate and stay resident. The real shortcoming of such memory-resident anti- viral programs is simply that they are memory resident- sitting right there in RAM. And just as virus scanners typically search for viruses which have gone memory- resident, a virus could search for anti-virus programs which have gone memory-resident. There are only a relatively few memory-resident anti-virus programs on the market, so scanning for them is a viable option. Finding scan strings for anti-virus programs is easy. Just load the program into memory and use MAPMEM or some similar program to find one in memory and learn what interrupts are hooked. Then use DEBUG to look through the code and find a suitable string of 10 or 20 bytes. Incorporate this string into a memory search routine in the virus, and it can quickly and easily find the anti-virus program in memory. The process can be sped up considerably if you write a fairly smart search routine. Using such techniques, memory can be scanned for the most popular memory-resident anti-viral software very quickly. If need be, even expanded or extended memory could be searched. Once the virus has located an anti-virus routine in memory, it has a number of options. It may simply go dormant. The virus will then stop replicating as long as the anti-virus routine is in memory watching it. Yet if the owner of the program turns his virus protection off, or passes the program along to anyone else, the virus will reactivate. In this way, someone using anti-viral software becomes a carrier who spreads a virus while his own system has no symptoms. Alternatively, the virus could simply trigger a logic bomb when it detects the anti-virus routine, and trash the hard disk, CMOS, or what have you. Such a logic bomb would have to be careful about using DOS or BIOS interrupts to do its dirty work, as they may be hooked by the anti-viral software. A number of options are avail- able: the virus could search the ROM BIOS for the initial interrupt 13H vector, or use detailed knowledge of the memory resident software it detected to unhook the necessary vectors. Alternatively, it could incorporate a routine to do direct disk 1/0. While doing direct disk 1/0 may be somewhat cumbersome, the code to do it is fairly easily obtainable, either from an AT Technical Reference manual or using a good disassembler on your own BIOS ROM, and a dedicated routine to trash a hard disk would not consume an unreasonable amount of space. Finally, the virus could play a more insidious trick. Suppose an anti-virus program had hooked interrupt 13H. If the virus scanned and found the scan string in memory, it could also locate the interrupt 13H handler, even if layered in among several other TSR'S. Then, rather than reproducing, the virus could replace that handier with something else in memory, so that the anti- virus program itself would damage the hard disk. For example, one could easily write an interrupt 13H handier which waited 15 minutes, or an hour, and then incre- mented the cylinder number on every fifth write. This would make a horrible mess of the hard disk pretty quickly, and it would be real tough to figure out why it happened. Anyone checking it out would probably tend to blame the anti-viral software. Of course, mixtures of these methods are also pos- sible. For example, a virus could remain quiet until a certain date, and then launch a destructive attack. The virus we are studying, RETALIATOR, in the configuration described here, is set up to pick on a popular anti-viral package, as noted in the source code. The normal install procedure of this anti-viral package will set one's system up to put a program VSAFE into memory at boot-up. This program hooks a number of interrupts and actively maintains checksums of ex- ecutable files, alerting the user to a change before a program is executed. RETALIATOR easily detects it in memory and jumps to a routine which announce,- "RETALIATOR has detected resident anti-viral software. TRASHING HARD DISK!" and proceeds to simulate the disk activity one might expect when a hard disk is being systematically wiped out. RETALIATOR was also written in such a way that it is easy to modify and add scan strings for different memory-resident anti- viral packages. Designing a virus which can retaliate against integrity checkers is a bit more complicated, since they don't reside in memory. It usually isn't feasible to scan an entire hard disk for an integrity checker from within a virus. The amount of time and disk activity it would take would be a sure cue to the user that something funny was going on. Since the virus should remain as unnoticeable as possible-unless it gets caught-another method of dealing with integrity checkers is desirable. One possible way to locate a non-resident anti-virus program in a discrete fashion is to look for it in its default location. Although such a technique is obviously not foolproof, most users (stupidly) never think to change even the default directory in the install sequence. Such , default search could be relatively fast, and it would allow the virus to knock out the system the first time it gained control. Such methods are unreliable at best, though. If imple- mented, they still need some kind of backup approach, since a simple directory name-change will thwart them. Apart from such scanning, a virus could check for chan- ges it has made to other executables and take action in the event that such changes get cleaned up. Of course, such an approach means that the virus must gain control of the CPU, make some changes, and release control of the CPU again. Only once it gains control a second time can it check to see if those changes are still on the system. Obviously, there is a certain amount of risk in any such operation. In between the first and second executions of the virus, the anti-viral software could detect the change which the virus made, and track down the virus and remove it. Then there would be no second execution in which the virus gains control, notices its efforts have been thwarted, and then retaliates. If, however, we assume that the virus has successful- ly determined that there is no dangerous memory-resi- dent software in place, then it can go out and modify files without fear of being caught in the act. The most dangerous situation that such a virus could find itself ir would be if an integrity shell checked the checksum of every executable on a disk both before and after a pro- gram was executed. Then it could pinpoint the exact time of infection, and nail the program which last executed. This is just not practical for most users, though, because it takes too long. Norally, an integrity checker is an occasional affair. You run it once in a while, or you run it automatically from time to time. So your integrity checker has just located an EXE file that has changed. Now what? Disassemble it and find out what's going on? Not likely. Of course you can delete it or replace it with the original from your distribution disks. But with a retaliating virus you really must find the source immediately. If you have a smart enough scanner that came with your integrity shell, you might be able to create an impromptu scan string and track down the source (if the virus didn't take precautions against that). If anything less than a complete clean-up occurs at this stage, though, one must live with the idea that this virus will execute again, sooner or later. If the virus you're dealing with is a smart, retaliating virus, this is an ominous possibility. There is no reason that a virus could not hide a list of infected files some- where on a disk, and check that list when it is executed. Are the files which were infected still infected? No? Something's messing with the virus. Take action. Trash that disk now! Alternatively, the virus could leave a portion of code in memory which just sits there guarding a newly in- fected file. If anything attempts to modify or delete the file, this sentry goes into action, causing whatever damage it wants to. And the virus is still hiding in your backup. Although these scenarios are not very pretty, and we'd rather not talk about them, any of them are rather easy to implement. The RETALIATOR virus, for ex- ample, maintains a simple record of the last file infected in Cylinder 0, Head 0, Sector 2 on the currently logged hard disk. (Note that RETALIATOR only replicates on hard disks. It is dormant on floppies.) This sector, which resides right after the master boot record is normally not used, so the virus is fairly safe in taking it over. When the virus executes, it checks whatever file name is stored there to see if it is still infected. If so, it infects a new file, and stores the new file name there. If the file it checks is missing, it just infects a new file. However if the file which gets checked is no longer infected, it proceeds to execute its simulated "TRASHING HARD DISK!" routine. Such a file-checking routine could easily be modified to check multiple files. Of course, one would have to be careful not to implement a trace-back feature into the checking scheme. To avoid being caught by a sophisticated scanner/in- tegrity checker, RETALIATOR is polymorphic. The virus has 512 nominally different signatures, and two ,which are totally different. Each time it replicates, it changes its signature. In conclusion, viruses which retaliate against anti- viral software are rather easy to create. They have the potential to lie dormant for long periods of time, or turn into devastating logic bombs. The only safe way to defend a system against this class of viruses is by using a smart scanner which can identify such viruses without ever executing them. For all its nasty habits, RETALIATOR could be easily spotted by a signature analyzing scanner which used thoughtful scan strings based on a disassembly of the virus. Viruses such as RETALIATOR could, in time, make it very dangerous to use simple integrity checkers or TSR's to catch viruses while giving them control of the CPU. RETALIATOR is by no means the most sophisti- cated or creative example of such a virus. It is only a simple, demonstrable example of what can be done. If anti-viral developers continue to turn away from scan- ners-as they seem to be doing-rather than developing a new generation of smarter scanning technology, we might end up being faced with the situation of really needing a smart scanner, and being faced with the pos- sibility that it won't be available for one or two years.